Attribute modifications lost / shareable edit

Hello,

we have an issue here where people claim that they have modified attribute values in a specific module (some days ago) in shareable edit, and the information is lost now.

Looking at the module now, the attribute values are empty for some objects, where people claim they have put in values, and there are no history entries for this attribute for those objects.

The losses can not be connected to complete sections, i.e. there are sections where attribute values are kept for some objects, while they are lost for others, within the same section.

Without any history entries it is of course diffcult to analyse from the client side what has happened, which is why I would like to ask whether

a) other people have experienced the same, and
b) whether the server produces log files in addition to what is stored in the history, which could be ueful to analyse.

Any comments appreciated,

best regards,

Peter
Peter_Albert - Tue May 17 06:54:43 EDT 2011

Re: Attribute modifications lost / shareable edit
llandale - Tue May 17 11:47:01 EDT 2011

Well, the default answer is that these folks forgot to save their modules, perhaps before the DOORS service crashed. It would be interesting to look at the Module Properties >>History >>Sessions, figure out which session they were in, then see if there is ANY history associated with those edit/share sessions.

But I have a nagging memory vis-a-vis a bug in this regard; perhaps someone else recalls it. Seems to me it went: A and B open M shared. A locks section S1, edits, and saves. B locks section S2 and saves, and this wipes out A's edits.

  • Louie

Re: Attribute modifications lost / shareable edit
educ - Fri Jul 08 02:45:09 EDT 2011

llandale - Tue May 17 11:47:01 EDT 2011
Well, the default answer is that these folks forgot to save their modules, perhaps before the DOORS service crashed. It would be interesting to look at the Module Properties >>History >>Sessions, figure out which session they were in, then see if there is ANY history associated with those edit/share sessions.

But I have a nagging memory vis-a-vis a bug in this regard; perhaps someone else recalls it. Seems to me it went: A and B open M shared. A locks section S1, edits, and saves. B locks section S2 and saves, and this wipes out A's edits.

  • Louie

Dear Louie,

We have a problem during shareable edition. I have a user A that yesterday performed some changes in two attributes. We are not able to see the changes in the attributes. However, the history of the object indicates the two modifications he claims he performed.

I don't know if this is a shareable problem or whether we have defined the attributes that it should Generate History but we have not defined the attribute to Affect change bars or Affect change dates.

Regarding this problem I have another case that is more complex. User A modified an attribute A1 to state X1, user B modified the same attribute A1 to state X2. User A had to check attribute A1 to modify another attribute A2. We see that the attribute A2 is modified according to A1= X2, but the attribute A1 is still in state X1. However the history shows properly all the modifications, it seems the attribute A1 does not reflect the last change to A2.

Thanks in advance and best regards,

Jose

Re: Attribute modifications lost / shareable edit
llandale - Fri Jul 08 11:23:59 EDT 2011

educ - Fri Jul 08 02:45:09 EDT 2011
Dear Louie,

We have a problem during shareable edition. I have a user A that yesterday performed some changes in two attributes. We are not able to see the changes in the attributes. However, the history of the object indicates the two modifications he claims he performed.

I don't know if this is a shareable problem or whether we have defined the attributes that it should Generate History but we have not defined the attribute to Affect change bars or Affect change dates.

Regarding this problem I have another case that is more complex. User A modified an attribute A1 to state X1, user B modified the same attribute A1 to state X2. User A had to check attribute A1 to modify another attribute A2. We see that the attribute A2 is modified according to A1= X2, but the attribute A1 is still in state X1. However the history shows properly all the modifications, it seems the attribute A1 does not reflect the last change to A2.

Thanks in advance and best regards,

Jose

Don't know. What version of DOORS?

Is this the exact sequence?:
  • Users 1 and 2 both share the module
  • User 1 locks a section, modifies A1 to "X1", saves and unlocks
  • User 2 locks the same section and modifies A1 to "X2", saves and unlocks
  • User 1 locks the section and modifies A2 to "X2", saves and unlocks.
  • before closing, User 1 notices A1 is still "X1".
  • Everbody notices the same thing.

If so, then I'd guess that DOORS failed to reload that section for user 1 after user 2 modified it; the reload should occur when 1 locks that section for the 2nd time.

And if so, you can prevent that by adopting the policy of downgrading the module to "read" or better yet closing it and then re-opening it "shared" before you lock a section.

Too lazy to look it up but this sure sounds like a known and fixed problem of some specific version of DOORS. Someone will surely respond to that invitation.

  • Louie

An evil person can simulate your symptoms. If you suspect that then we have more to talk about.

Re: Attribute modifications lost / shareable edit
educ - Mon Jul 11 04:27:43 EDT 2011

llandale - Fri Jul 08 11:23:59 EDT 2011
Don't know. What version of DOORS?

Is this the exact sequence?:

  • Users 1 and 2 both share the module
  • User 1 locks a section, modifies A1 to "X1", saves and unlocks
  • User 2 locks the same section and modifies A1 to "X2", saves and unlocks
  • User 1 locks the section and modifies A2 to "X2", saves and unlocks.
  • before closing, User 1 notices A1 is still "X1".
  • Everbody notices the same thing.

If so, then I'd guess that DOORS failed to reload that section for user 1 after user 2 modified it; the reload should occur when 1 locks that section for the 2nd time.

And if so, you can prevent that by adopting the policy of downgrading the module to "read" or better yet closing it and then re-opening it "shared" before you lock a section.

Too lazy to look it up but this sure sounds like a known and fixed problem of some specific version of DOORS. Someone will surely respond to that invitation.

  • Louie

An evil person can simulate your symptoms. If you suspect that then we have more to talk about.

Dear Louie,

We have a DOORS server with version 8.1.0.7 and the DOORS clientes are 8.1.0.6.

  • Users 1 and 2 both share the module
  • User 1 locks a section, modifies A1 to "X1", saves and unlocks
  • User 2 locks the same section and modifies A1 to "X2", saves and unlocks
  • User 1 and 2 close the module.

  • Another day, user 3 opens the module, and sees that A1 is in state "X1" but in the history of the object there is a last log indicating that A1 was modified to "X2", so we understand it could not show us the state "X1".

We can't understand this entry log in the history.

I don't know if it is because we defined the attribute A1 that it should Generate History but we have not defined the attribute to Affect change bars or Affect change dates.

Thanks again,

Jose

Re: Attribute modifications lost / shareable edit
llandale - Mon Jul 11 16:03:45 EDT 2011

educ - Mon Jul 11 04:27:43 EDT 2011
Dear Louie,

We have a DOORS server with version 8.1.0.7 and the DOORS clientes are 8.1.0.6.

  • Users 1 and 2 both share the module
  • User 1 locks a section, modifies A1 to "X1", saves and unlocks
  • User 2 locks the same section and modifies A1 to "X2", saves and unlocks
  • User 1 and 2 close the module.

  • Another day, user 3 opens the module, and sees that A1 is in state "X1" but in the history of the object there is a last log indicating that A1 was modified to "X2", so we understand it could not show us the state "X1".

We can't understand this entry log in the history.

I don't know if it is because we defined the attribute A1 that it should Generate History but we have not defined the attribute to Affect change bars or Affect change dates.

Thanks again,

Jose

I'm stumped. But it does sound like an old problem recently fixed; where History mis-matched the values. Seems to me there was a fix DXL for it.

  • Louie

Re: Attribute modifications lost / shareable edit
SystemAdmin - Wed Aug 10 12:16:41 EDT 2011

Jose,

I know that in 8.3 and beyond there is a tool that the Administrator can run called "check data against history". It's accessed in the module, under the Tools menu. Not sure if 8.1 had it or not.

Louie, you might be thinking of the issue (fixed in 9.2.0.5) that started with 9.3.0.3 where multiple users in sharable edit coudl create duplicate Absolute Numbers. Only Shareable issue discussed in fix-lists lately.

Re: Attribute modifications lost / shareable edit
educ - Fri Sep 23 08:10:29 EDT 2011

SystemAdmin - Wed Aug 10 12:16:41 EDT 2011
Jose,

I know that in 8.3 and beyond there is a tool that the Administrator can run called "check data against history". It's accessed in the module, under the Tools menu. Not sure if 8.1 had it or not.

Louie, you might be thinking of the issue (fixed in 9.2.0.5) that started with 9.3.0.3 where multiple users in sharable edit coudl create duplicate Absolute Numbers. Only Shareable issue discussed in fix-lists lately.

Hello,

We have seen this new tool in version 9.3 and have checked some of the modules. I am really worry because I have found several errors. There is one module that has up to 588 errors.

588 Attribute values not matching values in history.

There have been several people working on this module at the same time with sections and shareable edit.

We'll try to migrate our database to version 9.3.

Jose

Re: Attribute modifications lost / shareable edit
llandale - Fri Sep 23 14:24:31 EDT 2011

educ - Fri Sep 23 08:10:29 EDT 2011
Hello,

We have seen this new tool in version 9.3 and have checked some of the modules. I am really worry because I have found several errors. There is one module that has up to 588 errors.

588 Attribute values not matching values in history.

There have been several people working on this module at the same time with sections and shareable edit.

We'll try to migrate our database to version 9.3.

Jose

I doubt this is it, but History is stored in Session order, not in Date order. If user A opens shared (session n), then B opens shared (session n+1), locks edits (time t) and saves changes and unlocks, then A opens the same section and updates the same object (time t+s) and saves, you will find the History for A (an earlier session) before the History for B (a later session). But if you look closely at the Date of the History you will notice A (t+x) was after B (t).

Hate that they do that.

  • Louie

Re: Attribute modifications lost / shareable edit
MartinWilliams - Wed Oct 05 06:49:42 EDT 2011

Hello,
This rang historical alarm bells - I don't know when the fault was introduced but it was fixed in 8.2p1. The following is an extract from the readme of that patch. In some instances we had data more uptodate than the history so we did not use the utility intended to fix the resultant mess.

Defect fixed by 8.2 patch 01
Defect:- 25802
When a module is configured with hierarchical shared sections, it has been found that under certain circumstances the DOORS client can overwrite changes to a section. This has resulted in discrepancies between the history recorded for the module and the current data in the module. A new utility is included in this patch to identify and resolve the discrepancies.

To reproduce the problem, follow these steps:

Build the following structure in a module:

1.
1.1.
2.
Make all three objects sections.
Start two clients as different users and open the module in shareable edit in both clients.
In client 1, lock object 1, make an edit, then save and unlock the section.
In client 2, lock object 1.1, then either unlock the section without making any changes or make an edit, unlock the section and discard the changes.
In client 2, lock object 2, then make an edit, save using Ctrl+S, then unlock the section.
Close both modules.
Reopen the module in either of the clients and you will notice that the edit made by client 1 has now disappeared.
Patch 01 contained a new utility to fix the discrepancies caused by defect 25802.

The utility uses DOORS's history recording functionality to detect and fix discrepancies between the current data in a module and the history of the module. The following discrepancies can be detected and fixed:

Objects that have been deleted or undeleted in history, and aren't deleted or undeleted in the current data.
Objects that have been purged in history, and still present in the current data.
Links that have been created or deleted in history, and aren't present or are still present in the current data.
Attribute values where there is a difference between the current data and history, including text values, string values, enumerated values, integer values, real values, dates, or usernames. Also included are differences in default values, inherited values and module attribute values.
Changes to attributes and objects that weren't included in history recording cannot be detected by the utility.

Objects that were included in history recording and are not in the current data are reported in the log but cannot be recovered.

The utility produces a report of any discrepancies, and allows you to update a module with the differences.

There are a number of discrepancies that the utility cannot detect:

If OLE data wasn't included in history when the history record was saved, OLE data won't be included in the updated attribute value.
If the change recorded in the history record is simply adding an OLE object and no text to a text attribute that was previously, and is currently, empty, the discrepancy won't be detected.
If the value recorded in history isn't now a valid value for the attribute, then the tool will report this in the log, but it won't update the attribute value. This can happen as a result of changes in the attribute definition or type definition that have been made since the history item was recorded (for example, changing the values of an enumerated type).

good luck
regards
Martin